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(57) Abstract- A computer system provides an authorizer with the ability to set up and monitor individual accounts for one or more 
subordinates. Using the subordinate accounts, the subordinates can purchase items over a computer network, without direct access 
to a credit card, and subject to a combination of forms of purchase approval, purchasing restrictions, and paynicnt options The sys- 
tem provides feedback and suggestions to subordinates regarding purchases, and maintains a database with mforraauon about items 
previously selected by each subordinate. The database is used to create a personal catalog for each subordmate wiih mforrnauo., 
about items previously selected and ultimately purchased or not by the subordinate and others withm the group of subordinau:s. 
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METHOD AND SYSTEM FOR SUPERVISING ON-LINE PURCHASING 

Fi.MH nfrhe I nvention 

This inveniion relates lo methods and systems lot condaciing on-line purchases. 

5 

Background of the Invention 

Electronic commerce has been groveling at a rapid pace, and provides 
opponunitics lor companies to sell products to customers who are not physically present 
at a company's store. For many individuals, electronic commerce provides convenience 
and an ability to obtain better prices. However, the electronic commerce opportunities 
are considerably more limited Tor individuals who do not have credit cards or who need 
to obtain the approval of someone with purchasing authority before completing a 
purchase- These limitations arc particularly evident in the case of minors, who typically 
do not have credit cards or any other mechanism for purchasing items electronically. 
These limitations also are evident in various group or team buying situations, in both 
corporate and family settings. 

Recently, a number ot systems have been announced to attempt to meet the needs 
of minors- These systems include those described at www.allowancenet.com, 
www.cybermoola.com, www.doughboyxom, www.echargexom, www.icanbuy.com, 
www.pocketcardxom. and www.rocketcard.com. These systems employ various models, 
but appear to provide limited flexibiUiy and options. For example, these systems are 
limited in the variety and combination of purchasing approvals, purchasing restrictions, 
and payment options that are available to the parents or others with purchasing authority 
over children or others. These systems also are limited In how they use information 
25 about prior purchases and prior attempts to make purchases. 

Another limitation with existing electronic commerce systems is the lack of 
consumer-oriented purchase management systems that allow purchase selections to be 
managed and reviewed prior to the final purchase transaction. 
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gii TTiinnrv or the Invention 

According to ihe preseni invention, a supervisor, parent, or other individual, 
group of individuals, or entity with spending approval authority over others (an 
^^aulhorizer") establishes a master account and one or more subordinate accounts with an 
approval system. Each suhordinate account tjTjically corresponds to a family member or 
a member of a buying team (such as the members of a purchasing department) but could 
correspond to any individual or entity for which the aulhorizer has spending approval 
authority. An individual or entity for which an authorizer has such approval authority is 
identified generally herein as a subordinate. The combination of the ma.ster account and 
associated subordinate accounts is identified herein as a family of accounts. 

Through the master account, the auihorizer can individually determine how each 
subordinate will be permitted to make electronic purchases and what limitations will be 
imposed on the purchases a subordinate may make. For example, a .subordinate account 
may be set up so that the authorizer must approve each purchase before it can be 
completed. Or, purchases can be pre-approved, provided they meet certain criteria, such 
as criteria based on the type of item, the cost of the item, or the vendor. Criteria may be 
inclusive (only those items meeting the criteria may be purchased) or exclusive (items 
meeting the criteria may not be purchased). Where purcha.scs are pre-approved, a credit 
card, a bank account, or any other spending mechanism may be used. Like the approval 
criteria, the spending mechanism may be specified for each subordinate or for a type of 
transaction. The master account also permits the coordination of group purchases. 

Spending criteria and the approval mechanism can be separate. For example, 
even purchases meeting the criteria can require express approval by the authorizer. 

The authorizer also can configure the extent to which each subordinate receives 
notificaUons of items that are approved or rejected, and the extent to which each 
subordinate has access to personal catalog functions. 

Once the criteria and approval process are established, a subordinate may 
purchase any item matching the criteria (and subject to the approval process) that is 
available over a network or collection of networks, such as the World Wide Web. As 
long as the vendor recognizes the approval system, the transaction may be conducted. 
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The approval system, in addition lo being used to determine whether a purchase 
takes place, can provide feedback to the subordinate. For example, the approval system 
can explain the criteria to a subordinate who attempts to make purchases that do not meet 
the criteria, or can assist the subordinate in revising an order so as to meet the criteria. 

Optionally, the approval system maintains a database with intormaiion about the 
prior items examined and selected by each subordinate within a family of accounts, and 
(where appropriate) whether each item has been approved or not. This permits the 
creation of a personal catalog, based on items previously viewed or approved by a 
particular subordinate and/or by others within a family of accounts. 
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Rrief Descri ption of the Drawings 

Figure 1 is a block diagram of a computer network for use with an embodiment ot 

the present invention. 

Figure 2 Is a representation of a structure for a family of accounts according to an 

^5 embodiment of the present invention. 

Figure 3 is a flow diagram of steps performed according to an embodiment of the 

present invention. 

Figure 4 is a flow diagram of steps performed according to an embodiment of the 
present invention. 

Figure 5 is a representation of a structure for implementing a system according to 
an embodiment of the present invention. 

Figure 6 is a How diagram of steps performed according to an embodiment of the 

present invention. 

Figure 7 is a representation of a structure for implementing a system according to 
25 an embodiment of the present invention. 

Figure 8 is a representation of a structure for implementing a system according to 
an embodiment of the present invention. 

Figure 9 is a flow diagram of steps performed according to an embodiment of the 

present invention. 

Figures lOa and lOb are representations of structures tor implementing a system 
according to an embodiment of the present invention. 
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neiailpfi DL^scri ption of Preibrred Em bodimenLs 

Referring to Figure 1, networked sysiein 10 includes user sites 20, approval 
system 30, and vcndt)r presentations 40, all connected to network 50. In a preferred 
embodiment, network 50 is the World Wide Web; however, any other network, including 
a private or dedicated network could be used. User sites 20 include a personal computer 
configured to interact over network 50. For example, a user site 20 may include a 
multimedia-capable, Pentium IBM-PC compatible personal computer 22 running 
Microsoft Windows 95, 98. or NT, with a modem Tor connecting to the Internet. 
Personal computer 22 also runs an Internet browser, such as Microsoft Internet Explorer 
or the Netscape Navigator- 
Approval system 30 includes server 32 and database server 34 runnmg an Oracle 
or other database system 36. Depending on the si/e of approval system 30, server 32 and 
database server 34 could be a single physical server or multiple servers, as appropriate to 
25 meet the expected system needs. 

Vendor presentations 40 may consist of an online store in which products or 
services are presented for purchase. Such online stores may include a web server 42, an 
HTTP server 44, and databases 46. A vendor presentation also could consist of a product 
offer within the context of an online advertisement. Such an online advertisement 
20 typically consists of a specific offer for a specific product or .service within the context of 
an advertisement placed in a high-traffic web site. The advertisement may consist of 
HTML-based content running on an HTTP server. With an advertisement, a purchase 
may be initiated by interacting with the advertisement. 

As shown in Figures 2 and 3. in order to set up a family of accounts, an authorizer 
25 at a user site 20 accesses approval system 30 over network 50 (step 210). At step 215, 
the authorizer provides identifying information 1 12, such as name, address, and 
electronic mail address, for a master account 100, and lists each subordinate for which a 
subordinate account 102 is to be created. Approval system 30 assigns to roaster account 
100 an account ID 104 and password 106, at step 220, to permit items to be approved and 
parameters to be set or changed, as described below. Similarly, at step 225, authorizer 
provides identifying information 1 14 for each subordinate account 102, and approval 
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sysiem 30 assigns an account ID 108 and a password 1 10 for each subordinate account 
102. Optionally, the aiuhori/er and each subordinate may be pcrniiiied to change the 
assiened password. Approval system 30 stores this account information in database 
system 36. If desired, the master account can have multiple account ID'S (and 
corresponding passwords), so that multiple individuals can serve as authorizers. An 
authorizer subsequently can add or remove subordLiiatcs. 

Optionally, at step 230, after establishing each account, the authorizer establishes 
a default sei of parameters 120, which apply to each subordinate account unless 
overridden for that account. Parameters 120 are stored in database system 36. In a 
preferred embodiment, parameters 120 include payment information 122, pre-approval 
status 1 24, and purchase criteria 126. Approval system 30 can have one or more standard 
sets of criteria, which can be selected as is or modiJied. to simplify the establishment of 
the accounts. 

Preferably, payment information 122 includes one or more of the following: credit 
card information 130 for one or more credit cards, credit card proxies 132 for one or 
more virtual accounts, and account information 134 for one or more bank accounts 
(which can be either traditional or on-line banks). Any other payment mechanism, 
whether prepaid or credit-based, can also be provided. Where all transactions will 
require the approval of the authorizer, payment information 122 can be omitted, and 
2Q provided for individual transactions. 

Pre-approval status 124 identifies whether the authorizer must approve an 
individual transaction or whether an individual transaction is pre-approved, subject to 
meeting the purchase criteria 126. Optionally, multiple levels of approval can be 
established, so that certain types of purchases (those meeting specified criteria) are pre- 
approved, others (meeting other specified criteria or not meeting the criteria for pre- 
approval) require individual approval, and others are automatically rejected. 
Alternatively, all purchases meeting the specified criteria can be subject to individual 
approval. 

Purchase criteria 126 can be used to determine whether an item is in a pre- 
approved category, whether it falls within a category of items that must be individually 
approved, or whether it falls within a category of itenns that automatically are rejected. 
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Generally, items thai aulomatically are rejecied with be items that do not meet the 
purchase criteria either for prc-approval or to permit individual approval. If the purchase 
criteria detcntiine only whether an item is pre-approved, items not meetina the. purcha.se 
criteria may be items that require individual approval or may be items that aulomatically 
are rejected. It" no items are pre-approved, ilem.s mectini! the purchase criteria will 
require individual approval and items not meeting the purcha.se criteria aulomatically will 
be rejected. 

The criteria 126 can be inclusive criteria 140 or exclusive criteria 142. Inclusive 
criteria describe characteristics of items that may be purcha.sed, and exclusive criteria 
describe characteristics of items that may not be purchased. Inclusive criteria 140 and 
exclusive criteria 142 can be combined tor each category. Criteria 1 26 arc combined in a 
Boolean fashion to determine the category in which an item falls. 

The criteria 126 include absolute criteria, such as the price of an item, the type ot 
item (such as video game, book, clothing, or the rating of a video), the vendor, the day or 
lime, and specified words in the title or description of the item. These criteria can be 
combined, so that the price cutoff for an item depends on the type of item or the vendor. 
Criteria 126 also include relative criteria. Relative criteria can include, for example, the 
lotal amount selected by the subordinate from the vendor in this transaction, the total 
amount .selected from the vendor within a given time period (such as the past 30 days), 
the total amoum selected from all vendors within a given time period, and the total 
amount for items of a certain type or group of types (such as the combined amount spem 
on video games and music in the current month). 

Criteria need not be subordinate-specific. They can be cumulative for some or all 
of the subordinates. For example, in a business purchasing context, the criteria may be 
cumulative lo ensure that two team members do not purchase the same item. The criteria 
also can include specific items purchased by other subordinates within the applicable 
time period. For example, the criteria can limit all subordinates to a maximum of ten of 
the same items (whatever they may be) from an office supplies category. 

After establishing the default parameters (if desired), the aulhorizer establishes, at 
step 235, the parameters tor each subordinate account. If default parameters have been 
established, then this step may be omitted for any subordinate whose parameters are the 
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same as ihe dclauli parameiers. Similarly, it default parameters have been established, 
then only those parameters that differ from ihc defaults need to be established. 

The criteria can lie established in many different ways. For example, the criteria 
can be established in the following manner for a subordinate account. Fiist, as shown ai 
step 805 in Figure 9, the aiithorizer selects the subordinate account of interest. Next, at 
step 810, the aulhorizer enters a total budget amount and the time period covered by the 
budget amount (such as a month). The authorizer then indicates (step 815) whether 
purchases meeting certain criteria will be pre-approved. If so, the authorizer selects from 
previously entered financial accounts or enters a new account for making payments on 
this subordinate's account (step 820). Next, the authorizer identifies (step 825) a llrst 
budget segment. For example, a budget segment might be "school supplies.'" The 
aulhorizer then enters a percentage or amount of the budget for this category (step 830). 
If the budget docs not include categories or if certain criteria apply to all segments, the 
budget segment identifier is "all" and the percentage is 100 percent. The segment budget 
amount represents the amount of the total budget that is available for the segment. 
Although it cannot be greater than the total budget, the combined totals for the budget 
segments can exceed the total budget amount. For example, a subordinate may be 
permitted to spend up to 60% of the budget on school suppliers and up to 50% of the 
budget on clothes, but cannot exceed the total budget in doing so. After selecting a 
percentage or amount of the budget for the segment, the authorizer (step 835) enters an 
approval category (pre-approved, requires individual approval, automatically rejected). 
The authorizer also enters the criteria (step 840) that apply for that category. These could 
include, for example, approved (or disapproved) vendors for the segment, maximum cost 
of any one item, the days or times during which an item can be purchased, and 
description information about the items. The authorizer then has the option (step 845) to 
select another approval category for that budget segment. If so. the authorizer enters the 
new approval category (from step 835) and continues as before. When the authorizer has 
specified all of the approval categories for thai budget segment, the authorizer has the 
option to enter a new budget segment (step 850). in which case the aulhorizer repeats the 
steps beginnmg with step 825. After the authorizer has specified all budget segments, 
approval system 30 saves the budget segments (step 855) to database system 36. The 
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authorizcr then has ihc option (step 860) lo enter criteria tor another subordinate or to end 
this process. The authorizcr later can edit any ponions ol" the criteria. 

As shown in Figure 4, a subordinate desiring to purchase an item uses the World 
Wide Web to tmd one ur more items of interest (step 305) from a vendor presentation 40. 
The vendor presentation may be, for example, a vendor's online store, a vendor 
advertLsement, or any other web site that provides access to the vendor's items. Ai step 
310, the vendor (which could he, for example, the online store, or another web site or an 
agent able to provide the item) sends a request to approval system 30 for payment. To 
accomplish this, the subordinate provides an identification of the subordinate's account 
with the approval system to the vendor. The necessary information regarding the order is 
sent from vendor site 40 to approval system 30, preferably using an Extensible Markup 
Language (XML) gateway. The XML data is sent using Hypertext Transter Protocol 
(HTTP), using for example the Secure Socket Layer (SSL) for security. Alternatively, an 
electronic mail message or other communications channels could be used to send the 
order information from vendor presentation 40 to approval system 30. 

Upon receiving ihe request for payment, approval system 30 accesses database 
system 36 to compare (step 315) the items to the criteria established for that subordinate 
and determine the category for each item. Optionally, approval system 30 forwards this 
information to the subordinate by electronic mail or posts this information (at a site 
accessible only using the subordinate's password) so thai the subordinate can learn the 
status of each item (step 320). In addition, approval system can explain the purchase 
criteria to the subordinate or assist the subordinate in revising an order so as to meet the 
criteria, as explained below. 

Items meeting the purchase criteria then are further processed in accordance with 
whether the purchase is pre-approved. For each item (if any) that is pre-approved, 
approval system 30 determines the appropriate payment information 122 (step 330), 
previously entered by the authorizer, then sends the order along with the appropriate 
payment information 122 to the vendor (step 335). In addition, each of these items is 
added to database system 36 (step 340). 

Approval system 30 adds each item (il* any) for which individual approval is 
required to a daily list 150 (Figure 5) for that subordinate (step 350). Preferably, daily 
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lisi 150 includes entries 152 with the name of the ilenn, its price, the vendor, any available 
description of the item, and a link 1 54 to the web page lor that item. Alternatively, a 
single daily hsi 150 can be used lor all subordinates, in which case daily list 150 also 
includes the name of the subordinate in each entry 152. 

At the beginning of each day (or olhcr time period), list 150 is empty (step 510 in 
Fieure 6). During the day, approval system 30 may add items to hsl 150 as a result ot the 
subordinate seeking to purchase items (step 515). Also, the subordinate may access the 
list and delete items (step 520). At the end of the day (or other time period), approval 
system 30 sends all items on list 150 to an electronic mail address lor the master account 
(step 525). The authorizer then determines which items to approve, designates a payment 
mechanism (which can be a default mechanism), and returns that information to approval 
system 30 (step 530), using a wcb-bascd form, return electronic mail, or any other desired 
mechanism. The authorizer approves or rejects an item by clicking on the appropriate 
selection within approval field 156. Optionally, the authorizer provides reasons when 
15 rejecting an item. For each item that is approved, approval system 30 sends the order 
along with the appropriate payment information 122 to the corresponding vendor (step 
535). Each item, whether accepted or rejected, is added to database system 36 (step 540). 
As with the initial list of categories into which each item falls, approval system 30 m a 
preferred embodiment informs the subordinate of the items that have been approved and 
rejected (step 545). Alternatively, where appropriate, the subordinate Ls not informed. 
Finally (step 550), approval system 30 empties list 150, 

The authorizer need not approve or reject all items at one time. For example, the 
authorizer could approve two items from the list and reject a third item, exit from the 
approval system\s web site, then return later to approve or reject the remaining items. 
Once items have been approved or rejected in one session, that status is shown in 
subsequent sessions. 

As with items that are pre-approved or that required individual approval, items 
that were automatically rejected are added to database system 36 (step 360 in Figure 4) as 
items that were requested but rejected. 

As shown in Figure 7, items are maintained in database system 36 according to 
the subordinate, the item name or other identifier (including, where possible, a URL for 
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ihe web pauc showini! ihe ilem). the dale the suhoidinate requested the item, the item s 
price, ihc vendor of the item (including a URL for the vendor), the type of ilem, whether 
the item was approved or rejected, and the basis lor rejecting the item (if applicable). For 
example, an item might have been rejected because of its cost, because of the other items 
requested, or because the aulhofizer rejected it. This information permits the system to 
keep track of each subordinate's purchase history, which may be used by the auihorizer 
to review the purchase history, and also for determining the approval of subsequent items 
(as described above) or for establishing a personal catalog. Optionally, database system 
36 includes for each item a field indicating the approval category (e pre-approved, 
requires individual approval, automatically rejected) into which the item fell and a list ot 
the criteria applied in making the categorization. Where the authorizer provides reasons 
for rejecting an item, those reasons also may be included in databa.se system 36. 

Each subordinate has a personal catalog 160, as shown in Figure 8, which shows 
each ilem from database system 36 that the subordinate previously selected. Optionally, 
only items requested within a set time period (such as the past three months) arc shown, 
unless the subordinate requests a differem time period. In addition, personal catalog 160 
may be purged periodically of old entries. 

Each entry 162 in personal catalog 160 includes the name of the item 170, the 
date the subordinate requested the item 172, the price of the ilem 174. the vendor for the 
item 176, the type of item 178, whether the item was approved or rejected 180, and the 
basis (if applicable) for rejection of the item 182. Alternatively, the basi.s for rejection 
182 or other information can be omitted from personal catalog 160 either automatically 
or if specified by the authorizer. 

The subordinate is able lo view the personal catalog by pointing a web browser to 
the web site of approval system 30 and entermg the subordinate's account ID and 
password. While viewing the personal catalog, the subordinate can click on a vendor 
176, which provides a link to the vendor's web site. Similarly, the subordinate can click 
on an ilem 174, which provides a link to ihe location at the vendor's web site where the 
item is displayed. This provides a simple mechanism for repeat ordering. By clicking on 
the basis for rejection 182. the subordinate is able to determine whether the subordinate 
might now he able to purchase the item because conditions have changed. 
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Preferably, personal caialoe 160 also provides a link 188 lo the purchase criteria 
126 applicable to thai subordinaie. This permits the stibortlinate to understand the 
auLhorizaiion criteria. However, where appropnaic, access to this inlbrnnatiun c?m be 
omitted or limited. 

In a preferred embodiment, personal catalog 160 also includes a hnk 190 to 
inlormalion from the personal catalogs of other subordinates within the family of 
accounts. As appropriate, the autht>ri/,er can limit the fields from each entry Tor a 
subordinate that are visible to other subordinates. Also, each subordinate may be 
provided the ability to designate certain fields as private (by, for example, clicking on the 
identifier for the field), subject to override by the authorizer. A private field is not visible 
to other subordinates. Where information from other personal catalogs is available to a 
subordinate^ the subordinate can click on entries to view the vendor, item, or other 
information, as with the subordinate's own personal catalog. 

Personal catalog also includes table 192 showing the applicable total budget and 
J 5 budget segments, the total amount spent and remaining that period, and the amount spent 
and remaining for each budget segment. 

The information that approval system 30 sends a subordinate as to the categories 
into which items have been placed (step 320 in Figure 4) is illustrated in Figure 10a. 
Preferably, information 910 includes entries with the names of the items 912, the date the 
subordinate requested the items 914, the prices of the items 916, the vendors 918, and the 
types of the items 920. In addition, if an item or combination of items fails to meet any 
criteria for pre-approval, approval system 30 provides a description 922 of those criteria. 
For example, if the subordinate attempted to purchase an item for $200 but the maximum 
amount for any one item is $100, description 922 would show the maximum amount, but 
not other criteria (such as permissible vendors) that were not violated. Or, ii the 
subordinate attempted to purchase two items, each costing $75, from a category in which 
the total budget was $100, description 922 would show the budget category and amount. 
Approval system 30 also provides a link 924 to the applicable purchase criteria 126. 
Alternatively, all criteria are displayed, with those criteria that were violated shown in a 
different manner. 
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If the subordinaie clicks on adjusL order button 926, approval system 30 provides 
a table 930 (shown in Figure lOb) that permits the subordinate to try variations on the 
order, to sec how that would atYect the results. The top half of table 930 includes 
financial status 932, which shows the applicable total budget and budget segments, the 
total amount spent and remaining that period, and the amount spent and remaining for 
each budget segment. The bottom half of table 930 includes the information from Figure 
10a (the names of the items, the date ihc items were requested, the prices, the vendors, 
the types of the items, a list of the criteria that were not met, and a link to the applicable 
purchase criteria). Unlike the information from Figure 10a, the subordinate can change 
these entries to try different options. For example, the subordinate can delete an item and 
see how that would al'fect the results. Table 930 includes a "restore" button 934 that 
permits the subordinate to return to the original selection's and try again. 

While there have been shown and described examples of the present invention, it 
will be readily apparent to those skilled in the art that various changes and modifications 
may be made therein without departing from the scope of the invention as defined by the 
appended claims. For example, information from the personal accounts of other 
subordinates in a family of accounts could be shown along with the information from a 
subordinate's own personal account, with appropriate designations to indicate whose 
account it is. 

Also, the invention can be applied in different contexts. For example, the system 
can be used as a form of gift registry. Alter the authorizer establishes criteria, a 
subordinate can choose the specific items that the subordinate desires to receive as gifts. 
All items would be subject to individual approval The authorizer (or auihorizers), by 
'^approving" an item, would be purchasing one of the items for the subordinate. In this 
context, the subordinaie generally would not receive a notification when the authorizer 
approves or rejects an item. Different authorizers could approve different items off the 
registry, to buy different items for the subordinate. 

Accordingly, the invention is limited only by the following claims and equivalents 

thereto. 

What is claimed is: 
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Claims 

1 . A meihod tor conduciin^^ transactions over a network comprising the steps 

of: 

receiving from one or more vendors a set of items requested by a first user for 
purchase over a network: 

evaluatinjf each item in the set of requested items against one or more purchase 

criteria; 

for each item in the set of requested items that meets the purchase criteria: 

if the purchase of the item also is pre-approved, sending to the vendor ol 
the item information permitting the purchase of the item; 

if the purchase of the item is not pre-approved: 

sending to a second user a request for approval of the item; 
receiving from the second user a response to the request tor 

approval of the item; and 

if the response includes an approval of the item, sending to the 
vendor of the item information permitting the purchase of the item, and if the response 
mcludes a rejection of the item, providing to the first user a notice that the item was not 
approved; and 

for each item in the set of requested items that does not meet the purchase criteria, 
providing to the tlrst user a notice that the item does not meet the purchase criteria. 

2. The method of claim 1 , further comprising the step of establishing the 
purchase criteria with a plurality of sets of purchase criteria, each of the sets of purchase 
criteria being applicable to a different category of items. 

3. A method for conducting transactions over a network comprising the steps 

of: 

receiving from one or more vendors a set of items requested by a first user for 

purchase over a network; 

evaluating each item in the set of requested items against one or more purchase 

criteria: and 
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lov each iiem in the sci of requested items thai does not meet the purchase criteria: 
providing to the firsi user a notice that the item does not meet the purchase criteria and 
inlbrmaiion relating to why the item did not meet the purchase criteria. 

4. The method of claim 3, further comprising the steps ot: 

when at least one item in the set of items does not meet the purchase criteria, 
providing to the first user a representation of the set of items, receiving from the first user 
a proposed adjustment to the sei of items, and providmg to the first user notice of which 
items in the adjusted set of items would meet the purchase criteria and which items in the 
adjusted set of items would not meet the purchase criteria. 

5. The method of claim 3, further comprising the step of: for at least one item 
in the set of requested items that meets the purchase criteria: 

sending to a second user a request tor approval of the item: and 

receiving from the second user a response to the request for approval of the item. 

6. The method of claim 3, further comprising the step of: for at least one item 
in the set of requested items that meets the purchase criteria, sending to the vendor of the 
item information permitting the purchase of the item. 

7. A method for conducting transactions over a network comprising the steps 

of: 

establishing one or more purchase criteria for a first user; 

selecting a pre-approval status for items meeting the purchase criteria; 

receiving from one or more vendors a set of items requested by the first user for 

purchase over a network; 

evaluating each item in the set of requested items against the purchase criteria; 

and 

for each item in the set of requested items that meets the purchase criteria, 
determining the pre-approval status of the item. 

8. The method of claim 7, further comprising the step of: for each item in the 
set of requested items that is determined to be pre-approved, sending to the vendor of the 
item information permitting the purchase of the item. 
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9. The method of claim 7, riiriher cdmprising ihc step of: tor al least one item 
in the set or requested items that meets the purchase criteria and is determined not to be 
pre-approved: requesting approval of the item. 

10. The method of claim 9, wherein the step of requesting approval of the item 
^ includes sending to a second user a request for approval of the item. 

1 1. The method of claim 9, further comprising the step of: for each item in the 
set of requested items that is determined to be pre-approved, sending to the vendor of the 
item information permitting the purchase of the item. 

1 2. The method of claim 7, further comprising the step of selecting a re jection 
notification status for items that are not approved. 

13. The method of claim 12, further comprising the step of: for each item thai 
is not approved, if the selected rejection notification status includes providing 
notification, sending a notification to the first user for items that are not approved. 

14. The method of claim 13, wherein the step of sending a notification to the 
^5 first user for items that are not approved includes providing to the first user a notice that 

the item does not meet the purchase criteria and information relating to why the item did 
not meet the purchase criteria. 

15. The method of claim 14, further comprising the steps of: 

when at least one item in the set of items does not meet the purchase criteria, 
20 providing to the fu-st user a representation of the set of items, receiving from the first user 
a proposed adjustment to the set of items, and providing to the first user notice of which 
items in the adjusted set of items would meet the purchase criteria and which items in the 
adjusted set of items would not meet the purchase criteria. 

16. The method of claim 7, wherein the step of establishing purchase criteria 
25 includes establishing the purchase criteria with a plurality of sets of purchase criteria, 

each of the sets of purchase criteria being applicable to a different category of items. 

17. The method of claim 7, wherein the purchase criteria for the fu^st user 
include criteria based on purchases made by other users. 

18. A system for permitting transactions over a network comprising: 
a server programmed to receive purchase criteria for a user and pre-approval 

status criteria for items meeting the purchase criteria, programmed to receive over the 
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neiwork from a vendor a set of iiems requested by a user, programmed to evaluate each 
item in a set of items received from a vendor against the purchase criteria for the user, 
and programmed to determine, for each item in a set of requested items that meets the 
purcha.sc criteria, a pre-approval status of the item from the prc-approval status criteria; 
and 

a database system coupled tn the server the database system programmed to 
maintain the received purchase criteria and pre-approval status, and to maintain for each 
item received from a vendor whether the item meets the applicable purchase criteria and 
whether the item has been approved. 



30 



06/29/2005 15:59 FAX 7039161727 



MicroPatent 



121019/028 



WO 01/50305 



PCT/US00/3394I 



1 / 10 



Figure 1 



10 







22 














42 




44 




46 


V J 




V > 







06/29/2005 15:59 FAX 7039161727 



MlcroPatent 



©020/028 



WO 01/50305 



2 / 10 



Figure 2 



PCT/USOO/33941 



Credit Cards: 

I C.C. Proxy: 
1 Accounts: 



I Approval: 



Account ID: 
Password: 
ID Information: 



130 



130 



132 



121 



121 



124 



104 



106 



HZ 



120 



122 



Piircthase Criteria 



140 



140 



140 



14a 



142 



126 



100 



Account ID: 
Password: 
ID Into: 



108 



110 



IH 



120 



Subordinate Account 
Parameters 



102 



Account ID: 
Password: 
ID Info: 



108 



110 



IH 



120 



Subordinate Account 
Parameters 



102 



06/29/2005 16:00 FAX 7039161727 



MlcroPatent 



[21021/028 



WO 01/50305 



3 / 10 



Figure 3 



PCT/USOO/33941 



User Accesses 
Approval System 


210 


F 


User Provides 
Identifying 
Information 


215 


f 


Assign Account ID 
and Password 


220 




Establish Subord. 
Accounts 


225 






Add Defaults? 



No 



Yes 



Establish Default 
Parameters 



230 



Establish 
Parameters for 
Subordinate Acct's 



235 



06/29/2005 16:00 FAX 7039161727 



MicroPatent 



81022/028 



WO 01/50305 



4 / 10 



Figure 4 



PCT/USOO/33941 



User Selects 
Items of Interest 



Fails 
Criteria 



Add Item to DB 



360 




305 




Vendor Sends 






Payment Request 




r 




Determine 


310 


Category 




315 




Notify Subordinate 




of Categories 



320 



Pre-approved 



Determine 
Payment Info 



330 



i 



Send Order to 
Vendor 



350 



335 



Add Item to DB 



Yes 




06/29/2005 16:00 FAX 7039161727 MicroPatent 



WO 01/50305 

5 / 10 



Figure 5 





Daily List for 




Item 


Price Vendor Description 


Approve? URL 






YES NO 


YES NO 


YES NO 


^ YES NO 






156 .. 154 




152 




150 







121023/028 



PCT/USOO/33941 



06/29/2005 16:01 FAX 7039161727 



MicroPatent 



®024/028 



WO 01/50305 



6 / 10 



Figure 6 



PCTAJSOO/33941 



/^tart with Empty^ 
V List } 



Current List 







Forward List to 




Master Account 




525 






r 


Authorizer 




Decides on Each 




Item 




530 


i 


Approved Orders 




Sent to Vendors 




535 







510 












Delete Item from 


Add Item to List 






List 


515 j 




520 






r 







Add Items to 
Database 



540 



Inform 
Subordinate 



545 



Empty List 



550 



06/29/2005 16:01 FAX 7039161727 



MicroPatent 



ia025/028 



WO 01/50305 



PCT/USOO/33941 



7 / 10 



Ll 



d 
O 

CD 

cr 



"D 

> 
O 

Q. 
OL 
< 



Q> 



O 
■D 
C 

> 



o 



cr 
CC 



0) 

Q 



cr 



E 

0) 



CO 

c 

"S 
o 

-Q 
Z3 
CO 



06/29/2005 16:01 FAX 7039161727 MicroPatent 121026/028 



WO 01/50305 PCT/USOO/33941 

8 / 10 




06/29/2005 16:02 FAX 7039161727 



MicroPatent 



21027/028 



WO 01/50305 



9 / 10 



PCT/USOO/33941 



Figure 9 



Select 
Subordinate 
Account 



fvlQ X Purchases 
're-approved^ 



Establish Payrrient 
Mechanism 



Identify Budget 
Segment 



825 


r 


Establisr 
forSe 


\ Budget 
gment 


830 

1 




Select Segment 
Approval Category 




06/29/2005 16:02 FAX 7039161727 MlcroPatent 



0)028/028 



WO 01/50305 



PCT/USOO/33941 



10 / 10 



Figure 1 0a 



912 914 916 SIS 920 922 



Item Date Req. Price Vendor Type Criteria Vi olated 



910 



Purchase Criteria 



924 



Adjust Order 



926 



Figure 10b 



Budget 

Total Amount Amt Spent 



Amt Remaining 



Budget 
Segment 1 
Segment 2 
Segment 3 



Item 



Variations 

Date Req. Price Vendor Type 



Criteria Vi olated 



924 



930 



Purchase Criteria 



934 



RESTORE 



